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ABSTRACT 

This paper describes an application of the CCSDS 
Principle Network (CPN) service model to commun- 
ications network elements of a postulated In- 
tegrated Ground Data System (IGDS). Functions are 
drawn principally from COSMICS, an integrated 
space control infrastructure (Ref. 1), and the 
Earth Observing System Data and Information Sys- 
tem (E0SDIS) Core System (ECS) (Ref. 2). From 
functional requirements, this paper derives a set 
of five communications network partitions which, 
taken together, support proposed space control 
infrastructures and data distribution systems. 

Our functional analysis indicates that the five 
network partitions derived in this paper should 
effectively interconnect the users, centers, 
processors, and other architectural elements of 
an IGDS. This paper illustrates a useful applica- 
tion of the CCSDS Recommendations to ground data 
system development. 

Key Words: COSMICS, CCSDS, IGDS, EOSDIS, ECS, 
networks 

1. BACKGROUND 

In 1990, at the 2nd AIAA/NASA International Sym- 
posium on Space Information Systems, some of us 
proposed a unified information and control infra- 
structure for the coming space age. (Ref. 3) That 
paper described a system concept, referred to as 
the Cosmic Information and Control System 
(COSMICS), which integrates the necessary off 
line processing and support functions with the on 
line elements needed for aerospace craft control. 
The authors stated that a unified control facili- 
ty might: (a) Minimize life cycle costs, (b) Pro- 


vide for technological innovation and support 
evolutionary changes in social needs, (c) Evolve 
economically through cooperative and well placed 
additions of processors, communications, and 
control facilities, and (d) Make the latest tech- 
nology available to the widest distribution of 
users in the most timely fashion. 

The tasks required for control of spacecraft 
operations discussed in the COSMICS paper are 
similar to, and can be grouped into the same 
functional categories as, those identified for 
the Flight Operations Segment (F0S) of NASA's 
ECS. (Ref. 4) We distributed the combined func- 
tionality of COSMICS and the ECS segments across 
a network architecture comprised of the following 
architectural elements: 1) A user community which 
requires data services, 2) A mission operations 
element to control aerospace craft, 3) An element 
to accomplish information processing and distri- 
bution functions, 4) Governments, with both na- 
tional and international relationships, and 5) 
Industry. 

Space data systems are baing designed to imple- 
ment standardized and internationally agreed upon 
techniques of data handling, data classification, 
and data transmission. (Ref. 5) The Consultative 
Committee for Space Data Systems (CCSDS) has 
published recommendations in the following major 
areas: 

1) Architectural specifications for the CCSDS 
Principle Network (CPN). These define a conceptu- 
al model for data handling networks to provide 
end-to-end data services in support of space mis- 
sions. The CPN consists of an onboard network 
which resides on a spacecraft capable of orbit, a 
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ground network which communicates with the 
spacecraft, and a space link subnetwork for con- 
nectivity. (Ref. 6) 

2) Recommendations dealing with techniques for 
telecommand and telemetry (Ref. 7,8), and 

3) Specifications for standardized data units, as 
well as for tine code formats, radioaetric and 
orbit data, radio frequency and modulation sys- 
tems, ground networks, and other topics. 

Recent work by the CCSDS has centered on develop- 
ing recommendations to make possible cross-sup- 
port services. (Ref. 9) As defined, this class of 
services will enable space agencies to bidirec- 
tionally transfer data from other space agencies 
between ground and space systems. (Ref. 10) It 
has the potential, through standardized implemen- 
tations of data units and communications services 
to make possible apparently seamless network 
implementations, as seen from user perspectives. 
Work has concentrated on the services which will 
be provided at ground interfaces, referred to as 
Service Access Points (SAPs), where services 
would appear eiternally as functions and capabil- 
ities would be made available by a providing 
agency to a requesting agency. (Ref. 11) 

2. ARCHITECTURAL ELEMENTS 

In our view, the top level architectural elements 
needed for an IGDS parallel those described for 
EOSDIS. (Ref. 12) We include a government archi- 
tectural element to those to implement a global 
infrastructure. The top level architectural ele- 
ments, then, are as shown in Figure 1. 

1) User Community. This would consist of a broad 
range of scientific and academic users in widely 
dispersed facilities. Government users would ac- 
cess the IGDS for general policy, planning, man- 
agement and operation of the IGDS, and to exert 
operational direction. Commercial and industrial 
users would include developers of applications. 
Individual users and organized user groups would 
desire access to segments of the IGDS. 

2) Mission Operations. Elements which correspond 
to those in COSMICS and the Flight Operations 
Segment of EOSDIS would be needed to implement an 
IGDS. 

3) Information Processing and Distribution ele- 


ment. A system similar to the backbone network 
element in EOSDIS would be needed in an IGDS. We 
combined components of the EOSDIS Science Data 
Processing Segment (SDPS) and Communications and 
System Management Segment (CSMS). 

4) Government. Governments can be expected to 
interface at the space agency level to provide 
for national goals and to establish the basis for 
cooperation. (Ref. 13) Organizations such as 
INMARSAT and INTELSAT might provide suitable mod- 
els. 

5) Industry. A suitable system of interfaces be- 
tween industry and IGDS system management would 
be needed to provide for development of a wide 
range of services. Governments might guarantee 
delivery of data products to vendors at network 
interface points, for example. 

3. IGDS FUNCTIONALITY 

In order to derive communications subnetwork 
partitions to support a functional IGDS, we par- 
titioned the IGDS functions into independent sets 
which night be accomplished in cooperation. Our 
analysis indicates the functional partition at 
Table 1 to be adequate. Our methodology paral- 
leled Halford’s architectural development frame- 
work. (Ref. 14) 

We imposed the structure described by Witworth 
(Ref. 15) to govern the relationship between the 
ground systems, space segments, and data users in 
typical space missions. We included the major ECS 
functions in our analysis (Ref. 16). A discussion 
of each of our functional categories follows. 

1) Data User Services. These functions control 
design and implementation of those aspects of the 
network which directly interact with the end 
user. (Ref. 17) These functions ensure that users 
need not know details about the IGDS to effec- 
tively use it. We formed two functional groups 
from these: (1) Data operations, to process and 
distribute bulk data, and (2) User support, to 
provide user interfaces. 

2) Mission Operations. We based this set of func- 
tions closely on the ECS Flight Operations Seg- 
ment (FOS). We formed four functional categories: 

(1) Aerospace craft operations performed by 
worldwide communications and tracking facilities, 

(2) Mission planning and scheduling, (3) Person- 
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nel training, and (4) Engineering support con- 
ducted by science investigators and national 
centers primarily to solve technical problems 
which occur during missions. 

3) IGDS Manageaent and Operations. These func- 
tional categories provide for international par- 
ticipation by government and industry. They ex- 
tend functions assigned to international partners 
in the ECS. 

4) Network Services. We organized these functions 
according to the principles explained by Salford 
for communications network overlays. (Ref. 18} 

This functional grouping reflects an overlay 
structure wherein the IGDS couunications network 
is to be realized as mutual ly exclusive subnet- 
works having characteristics deterained by at- 
tributes required at appropriate levels of 
abstraction. 

Our analysis of couunications network services 
yields the following functional categories: (1) 
Network Manageaent, which includes planning, 
operation, and administration of the coaaunica- 
tions network, (2) and (3) The Space and Ground 
Segments of the communications network, (4) Pro- 
cess support, which provides the services and 
functions needed by communications networks. Be 
included applications development functions, 
which consist of the tools and techniques for 
developing and maintaining the applications 
provided by the IGDS to its users, in process 
support. It became apparent that, from the users' 
perspective, data processing applications ser- 
vices could best be supported by the network if 
treated in much the same fashion as other process 
support services. 

4. NETWORK ORGANIZATION 

We partitioned the IGDS into subnetworks using 
the following procedure: 

1) We correlated the architectural elements dis- 
cussed in Part 2 of this paper with the IGDS net- 
work functions discussed in Part 3 above. Our 
correlation produced an assignment of each func- 
tion to one or more of the elements. We distin- 
guished between the following four levels of 
involvement for each assignment: (a) Primary re- 
sponsibility for accomplishment, (b) Collateral 
responsibilities, (c) Participatory, and (d) Non- 
participatory. 


2} Next, we grouped the functional assignments 
into subnetwork overlays. We prioritized each 
overlay with regard to the criticality of the 
functions it contained. Criteria included 
timeliness and security. 

3) We then grouped the subnetwork overlays info 
network partitions which could be implemented and 
controlled independently to sake the IGDS fully 
functional. 

Our analysis indicates that communications net- 
work partitions to support an IGDS could be 
implemented as five independent network parti- 
tions. These are shown in Table 2 and described 
below. 

1) An Operations high speed, highly critical top 
priority network, which connects the Aerospace 
Operations and the Information Processing and 
Distribution architectural elements. This network 
supports the core operations mission functions. 
Connectivity is extended to elements of the Dser 
Community element on a case-by-case basis to 
enable payload command functions. 

2) A less critical Engineering Support network 
which connects the same architectural elements as 
the Operations network. It is an entirely off- 
line support environment. 

3} A Data Processing network partition, confined 
to the Information Processing and Distribution 
architectural element, supports the high volume 
bulk data services which are at the heart of the 
IGDS. It connects the largest, most powerful data 
processors and archive facilities worldwide in 
support of the other IGDS functions. 

4 and 5) We divided the remaining IGDS functions 
between two separate network partitions. Each are 
broadly connected to all of the IGDS architec- 
tural elements. The Communications Support net- 
work is the more critical of the two and provides 
the coaaunications services. The other, the Dser 
Support and Administration network partition, 
provides those functions which manage the IGDS 
and determine the interface between the IGDS and 
its user community. 

Our analysis indicates that an IGDS might be 
developed as independent but complementary imple- 
mentations of the above five network partitions. 
As mentioned in the first section of this paper, 
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the CCSDS recommendations describe a wide variety 
of communications protocol standards which are 
being developed or adopted for use on space mis- 
sions during the coming decades. The architecture 
features extensive onboard and ground coaputer 
networking within the worldwide OSI framework in- 
tegrating digital transiission of video, audio, 
telemetry, and coaputer data. (Ref. 19) The CCSDS 
architecture supports end-to-end data couuni- 
cation across networks connected to the CPN via 
gateways using cross-support services. (Ref. 20) 

In the next section we review the status of ef- 
forts to develop cross-support data services. 

5. DATA SERVICES 

CCSDS Panel 3: Systea & Cross-Support has been 
working to develop the services needed to 
transfer data across networks froa different 
agencies participating in the CPH. It has concen- 
trated on the services which will be exchanged at 
the ground interface, referred to as Service 
Access Points (SAPs), between the networks for 
space operations. (Ref. 21) 

The Panel defines a service as 'the external 
appearance of functions and capabilities Bade 
available by a providing agency to a requesting 
agency". It developed the following four classes 
of 24 aajor services: (1) Conventional Telemetry 
and TelecoBoand, which consists of data services 
for these functions; (2) Advanced Orbiting Sys- 
tems (AOS), which extends the packetized AOS ser- 
vices previously defined on the CPN across the 
SAPs thereby Baking them accessible to agencies; 
(3) Nontelematic Spacecraft Monitor and Control 
facilities; and (4) New Services, which include 
facilities for reliable transport, file transfer, 
message service, and other services specialized 
to established space link services. 

The scheme described by one of the Panel 3 aem- 
bers, A. Hooke, appears to efficiently aap space 
link services into IGDS services in a way which 
can provide projects with a consistent view of 
services while controlling user access to the 
most critical of those services. Online mission 
control and data acquisition would, under this 
scheae, be provided by two independent service 
domains: 1) A Space Operations Data Services 
(SODS) segaent, and 2) A Flight Operations Ser- 
vices (FOS) segment. SODS would provide the vir- 
tual and physical channel coaauni cat ions services 
between ground elements and aerospace craft which 


require little or no mission-unique setup. FOS 
would provide customized services for particular 
projects. FOS would provide operations support 
and end system services, such as flight dynamics, 
flight monitor and control, and flight planning. 

A third independent service domain, the Space Ap- 
plications Service Infrastructure (SPSI), would 
provide user data analysis and distribution ser- 
vices to the IGDS User Community. This structure 
is shown in Figure 2, which is adapted from the 
Panel 3 report. 

6. CONCLUSION 

Froa a functional analysis of proposed aerospace 
control and information systems, this paper con- 
cludes that an IGDS might be effectively support- 
ed by five independent communications networks 
interfaced to CCSDS cross-support service 
domains. Each network partition would be tailored 
to one of the following functional areas: (a) Op- 
erations, (b) Data Processing, (c) Engineering 
Support, (d) Communications Support, and (e) User 
Support. It proposes that the interfaces between 
these network partitions and aerospace craft 
conform to CCSDS cross-support recommendations in 
order to provide an integrated information and 
control infrastructure. 
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Figure 1. Architectural elements comprising an IGDS. 
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Table 1. Functions {irtorma3 i>^ integrated Ground Data System 
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PRIOR ITT 
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PRIORITT 1 
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PRIORITT 4 


2 . 1.1 
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2.1.3 

2.1.4 
4.1.3 


CONTROL 
OPERATIONS 
PATLOAD COMMANDS 
VEHICLE COMMANDS 
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4. 1.3.1 PERPORHANCE 
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ARCHITECTURAL ELEMENTS 


USER COMMUNITY 

AEROSPACE 

OPERATIONS 

INFORMATION 

PROCESSING 4 

DISTRIBUTION 

( IP4D) 


1 USER COMMUNITY 

2 AEROSPACE 
OPERATIONS 

5 1P4D 


USER COMMUNITY 

AEROSPACE 

OPERATIONS 

GOVERNMENT 

INDUSTRY 

IP4D 


USER COMMUNITY 

AEROSPACE 

OPERATIONS 

GOVERNMENT 

INDUSTRY 

IP4D 


Table l. Five network partitions support: the functions needed to implement 
the proposed Integrated Ground Data System (IGDS). Each network has the 
priority indicated in the first column. The remaining two columns list the 
functions, keyed to Table 1, performed by each network partition and the 
architectural elements, keyed to Figure 1, served by each partition. 
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Figure 2. IGDS Infrastructure 
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